Computing systems have revolutionized the way we work and play. Computing systems come in a wide variety of forms including laptop computers, desktop computers, personal digital assistants, telephones, and even devices that have not been conventionally associated with computing systems such as, for example, refrigerators and automobiles. Computing systems may even comprise a number of constituent computing systems interconnected via a network. Thus, some computing systems may be small enough to fit in the palm of the hand, while others are spread over much of the globe.
One area of computing technology that has become increasingly popular is graphical modeling, which allows a user to visually display graph-like diagrams such as flow diagrams of numerous systems, services, or processes. Examples of diagrams include work flow diagrams, data flow diagrams, E-R diagrams, business process diagrams, and the like. More specifically, such graph-like diagrams allow users to visually communicate the functionality, behavioral aspects, and relationships of the various components or elements for different computing or other systems, business or project models, or the like; thus allowing for the efficient communication of often complex systems or processes.
For example, a graph-like diagram may visualize the flow of a sales transaction. The elements and components of the flow diagram may represent such events as selecting desired products, placing an order, arranging delivery and payment. The diagram may also visualize the entities that perform the tasks listed above. For very complex sales transaction with numerous entities involved, viewing the transaction graphically may be easier to comprehend than in other forms.
While graph-like diagrams are useful in visualizing systems and processes, there are limitations on their usefulness. For example, as the diagrams get larger and more complex, there may simply not be enough room to display all of the components and elements due to the size, resolution, and other capabilities of the display device. In other words, the available display space and capabilities limit how many components and objects can be viewed at one time. This is especially problematic for diagrams where a user desires to display both the beginning and end of a process.
One solution would be to use a larger display device. However, this is impractical for most users because of the cost this would entail. In addition, the diagrams may become so large that no practical display device could display all of the elements of the diagram.
Another solution to the display limitation commonly used is having the user manually rescale the diagram. For example, users will often “zoom out” anytime a new element is added to a diagram. While this solution may be effective for a diagram with only a few elements, it does not work well for larger diagrams. The diagrams often become unreadable after being zoomed out several times.
Another common solution is making multiple diagrams that together contain all of the required diagram elements in a readable size. However, this often can be time consuming. In addition, the flow or “mental map” of the diagram is often lost using multiple diagrams, which can be frustrating to a user.
A further solution has been to create tools that automatically layout the elements of the diagrams in an attempt to scale the diagrams in a readable form. However, such tools implement complex algorithms whose computational complexities make them very slow to process. Anytime a new element is added to the diagram, the tools must reprocess the algorithms and create a new diagram, making such tools impractical for an interactive editor. Further, most of these algorithms reposition every element of the diagram when a new element is added. As a result, the user often looses his or her “mental map” of the diagram, which can be annoying.